
\section{Retrospectiva}

\textbf{La implementación:}

Elegimos para implementar el sistema la plataforma Android. Basamos esta elección en varios aspectos.
El primero es que es no contamos con lo necesario para hacerlo en otras como  en Mac, por lo tanto fue elegida 
más que nada por descartar imposibilidades.
Dado que tampoco conociamos el desarrollo en Android
hemos contado con numerosos inconvenientes para poder hacer andar la parte de mapas y la lentitud para ejecutar hizo 
tedioso el desarrolar y probar la aplicación.

Ningún integrante del grupo conocía la herramienta  previamente, si bien evitamos asimetrías a la hora de acercarse al 
aprendizaje de dicha plataforma, provocó retrasos, producto de estimaciones
con un fuerte desvío de lo real.

Para emular el smartphone, usamos el Genymotion
Nuestros tiempos, no tuvieron relacion con los que logra un equipo de programadores profesionales con experiencia en estas 
herramientas debido al desconocimiento.

Terminada esta iteración sólo hemos conocido apenas una pequeña parte de la plataforma.

\begin{figure}[H]
\centering
  \includegraphics[width=0.3\textwidth]{runForest.jpg}
  \label{appEmulador}
  \caption{Captura de pantalla de la aplicación corriendo en el emulador.}
\end{figure}


\textbf{Diseño:}

Con respecto al diseño, nos costó arribar al diseño definitivo y fracasamos en los primeros intentos, haciendo varios diseños 
que adolecian de buenas propiedades como consecuencia del proceso paralelo de aprendizaje de patrones de diseño.

A medida que ibamos aprendiendo patrones, encontrabamos que los diseños que habiamos hecho eran muy poco flexibles y no cumplian 
con lo que se esperaba.

Algunos patrones de diseño utilizados como el observer emergieron naturalmente en el porceso de diseño,otros como el state fueron una respuesta a 
una necesidad de combinar cosas.

También surgieron inconvenientes a la hora de programar. Quisimos implementar el diseño y al hacer los 
diagramas de secuencia,  este proceso reveló falencias en el diseño que no habían sido contempladas.

Si bien fuimos construyendo la solución de manera iterativa incremental cabe aclarar que no usamos test driven development.

No contar con el diseño definitivo a tiempo nos atrasó bastante, y eso se ve reflejado en el burndown chart, no obstante, invertir tiempo en el diseño ayudó al encarar la programación.

\textbf{La Metodología:}

La metodología de SCRUM no se aplicó puramente, debido a que nunca tuvimos un scrum master, y algunas tareas no las actualizamos en un 
tiempo pertinente por dudar e su completitud.

Acorde con el ciclo iterativo, imaginamos para futuros sprints aumentar la productividad del equipo y también afinar las estimaciones, sobre
todo la velocity. 

La estimación de la velocity no fué muy buena porque el desarrollo y completitud de tareas no fue proporcional en todos los momentos de 
la iteración, por el contrario, muchas cosas se resolvieron al final y no al principio.

La metodología nos ayudó a saber en todo momento en donde estamos posicionados y saber a dónde tenìamos que llegar, debido a que las tareas fueron específicas y estaban bien definidas para la iteración.

Sin embargo, nos encontramos con que la metodología no nos ayudó en ciertos aspectos del proceso, por ejemplo, como la misma no menciona nada respecto a dependencia de tareas, entonces nos pasó que nos dividimos las tareas y mientras se estaba haciendo el diseño se intentó realizar a la par los diagramas de secuencia y nos encontramos con que, sin el diseño definitivo, no podíamos tener los diagramas ya que nos faltaban colaboraciones o mensajes. Por ende, tuvimos que esperar a tener el diseño definitvo para hacer la tarea de los diagramas. 

Por otra parte, no hay forma de reflejar que algunas tareas puedan realizarse en conjunto, como fue en nuestro caso la construcción del diseño. Es otra falencia que encontramos en la metodología.



